The Continuous Delivery track at the JAX London conference 2017!

You’ve made a decision: You’re going to do continuous delivery (CD) as the first step in your DevOps transformation. You’ve laid the groundwork. You’ve established the basic prerequisites necessary for a shift to a CD mindset: everything from ensuring your teams have shared goals to automating and versioning everything – both the application and the environment supporting it – to making sure application versions are ready to ship to production.

Now what? You’re ready to actually implement CD. How do you get started?

Because CD is a process – and not a flick-the-switch action – you are going to need to have a plan, implement it, take a few steps and be prepared to reevaluate, revise and revive as you go along. You are changing your organization’s whole culture, promising a better methodology to deliver better software. You’re not going to accomplish it all in one try. But you can get started and you can succeed, if you take it slowly and push forward one step at a time. Here are a few steps successful companies have taken to implement CD.

Pick a small, manageable project to start

A common mistake organizations make is trying to do too much too soon. CD enthusiasts believe in the methodology, and they tend to want to generate big gains quickly to justify the organization’s commitment. So they go for broke and tryto tackle a complicated project, with many twists and turns. The “big bang” approach promises big payoffs, but it tends to create big problems.

A better way is to start with a small, greenfield project that lets the organization try out CD and get used to the new procedures. Try to pick a new area with new delivery expectations
that isn’t tied to a legacy pipeline and an old set of procedures. Small, incremental changes to applications are easier to test – and easier to remedy if something goes wrong. Each change can be pushed through a pipeline more quickly, allowing organizations to do shorter, faster pipeline runs that can produce measurable, positive results.

Define a process

Once you’ve picked your initial project, you’ll need to define the process. This is as simple as writing the procedures on a board. Those of us that have read Gene Kim’s book “The Phoenix Project” are familiar with this step. The company highlighted in the book was encountering every IT delivery problem imaginable – until Bill Palmer, VP of IT, implemented continuous delivery. The first step was to get each staffer to write out steps in the delivery process on a whiteboard and think about how to link them, creating an assembly line process. The team then rolled up their collective sleeves, created a workflow and automated it.

The fact is, you can buy a great set of tools, create an aggressive set of goals and get your team to buy in. But until you map out a process, understand the process and assign roles, you can’t get started.

Ensure a blameless culture

Cyrille Le Clerc’s outline of the prerequisites to a CD implementation included a requirement that the development, QA and operations teams need to have shared goals. That’s essential. But it’s not the end of the “people work.”

As you implement CD, you should do an ongoing check that you’re truly promoting a blameless culture. Issues will crop up in any CD implementation, and your organization needs to ensure that it can triage them in a positive way without having people point fingers at each other. Successful DevOps cultures accept failure and promote risk-taking. Moving to CD is a risk, and your team needs to keep its head in the game to continuously improve your processes.

Set metrics and measure your success

Forrester analyst Kurt Bittner isn’t the only thought leader to preach the need to repeatedly quantify the value of a project. But he does present as clear a case as anybody about what to
measure in a software delivery project and how to apply those metrics to every step of the process. The fact is, you can’t improve if you don’t measure – early and often. So, an important move as you embark on a continuous delivery journey is to decide what you want to improve and how you’re going to measure improvement. Then, you set a series of baseline measurements. And you’re off.

Adopt configuration as code

A key aspect of continuous delivery is the ability to automate your configuration. This configuration-as-code DevOps practice ensures consistency in your CD process, clearing away problems that could result from rebuilding your confguration – potentially inconsistently – every time you want to push a release to production.

If you’re implementing CD, you’ll want to make sure you’re taking advantage of tools that enable configuration management – tools from Chef, Puppet and others. And we’re seeing more DevOps operations implement these tools. According to a recent DZone survey sponsored by CloudBees, 49 percent of organizations use a configuration management tool and 48 percent use a version control system for infrastructure changes and system definition. But, on the flip side, 73 percent still have to use manual scripts for at least half of their infrastructure changes.

Orchestrating a process

You’ve defined your pipeline; now you need to orchestrate it. This is a long process, but here are a few steps you’ll want to take – as outlined in a whitepaper by Xebia Labs’ Andrew Phillips and CloudBees’ Kohsuke Kawaguchi.

• Ensure reproducible builds – Configure the build system to use a clean repository connected to the build job’s workspace and use a central shared repository for build dependencies.
• Share build artefacts through the pipeline – Ensure the candidate artefact is used by all subsequent builds in your pipeline.
• Choose the right granularity for each job – Distribute all steps in the pipeline across multiple jobs, allowing you to identify bottlenecks more easily.
• Visualize the pipeline – Create a clear, accessible view of the build pipeline to allow for smooth status communications and transparency of the process to the business managers and other stakeholders.

Conclusion

Continuous delivery can initially seem to be a daunting challenge, but it’s a journey worth taking. There are tools at your disposal, including many freely available Jenkins plugins, to
make the task more manageable. With a little nerve and a lot of forethought, you can get started on a CD project that will ultimately generate tangible benefits for you, your teams, your company and your customers.